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(57) Abstract: This invention relates generally to 
processing re-quests coming from a client to a network 
server. In the arrangement according to the invention 
an HTTP request coming from a client's terminal is 
received in an HTTP server from where it is picked 
up by a request handler. The HTTP server contains an 
application for receiving the client requests and sending 
responses, a queue for the received client requests, and 
another queue for the responses. The HTTP server is 
. situated outside the firewall, and the request handler 
inside the firewall, as are back-end systems for the 
request handler as well. Since the request handler 
requires the HTTP server to return a client request in the 
re-quest queue as a response to the handler a connec-tion 
through the firewall is opened inside the firewall. 
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Arrangement for processing client requests 

Field of the Invention 

5 This invention relates generally to processing requests coming from a 
client to a network server. More particularly, the invention relates to 
HTTP requests. Furthermore, the invention relates to a security ar- 
rangement for services. 

10 Background of the Invention 

At present, server arrangements providing services usually contain a 
firewall, as in FIGS. 1 and 2. The firewall is a security element whose 
purpose is to keep unwanted service requests out of the service provid- 

15 ing systems. There are two types of firewalls: filtering firewalls that 
block selected network packets, and proxy servers that make network 
connections for you. Anyway, it is convenient to think about firewalls as 
packet filters. Data is only allowed to come to the system if the firewall 
rules allow it. As packets arrive they are filtered, for example, by their 

20 type, source address, destination address, and port information con- 
tained in each packet. 

FIG. 1 shows an example of a possible arrangement at present. Cli- 
ents' terminals 1 send service requests 8, such as HTTP requests, 

25 through a firewall 2 to a HTTP server 4. The requests are directed to 
the right applications 5, such as CGI (Common Gateway Interface), 
API (Application Programming Interface), ISAPI (Internet Server Appli- 
cation Programming Interface), or Java Servlet, which handle the for- 
ward processing of each request. The application can use middleware 

30 services 6 for processing the request sent forward 9 in a back-end sys- 
tem, i.e. in the system behind the HTTP server. The middleware proc- 
essing element 6 can use a database 7 for asking 10 necessary data 
needed for establishing the service requested. The database returns 
the request 11 as a response back to the processing element or di- 

35 rectly to the application. Alternatively, the application can have a direct 
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connection to a relevant database. The applications 5 send 12 re- 
sponses to the clients' terminals through the firewall. 

All connections between the clients* terminals and the HTTP server go 
5 through an allowed "hole" 3 in the firewall. The hole lets the packets 
which are not filtered away go through. However, in situations as in 
FIG. 1 the firewall has to allow HTTP traffic to go through due to the 
firewall being situated between the clients' terminals (in the Internet) 
and the HTTP server. Since the HTTP traffic amount is very huge the 
1 o firewall cannot establish a very efficient security effect. 

Another problem which appears in the system of FIG. 1 is that the con- 
nection to the applications and the back-end system are opened (es- 
tablished) outside the service providing arrangement. This exposes the 
15 arrangement to thousands of simultaneous HTTP requests, which can 
create an overload situation in the service arrangement, and even 
crash the arrangement. Naturally, service providers do not want this to 
happen. 

20 FIG. 2 shows another example of a possible arrangement at present. 
Clients' terminals 1 send service requests 8, such as HTTP requests to 
a HTTP server 4. The requests are directed to the right applications 5, 
which handle the processing of each request forward. The application 
can use middleware services 6 for processing the request sent forward 

25 9 in a back-end system, i.e. in the system behind the HTTP server. The 
requests 9 sent to the back-end system go through a firewall 2A. The 
middleware processing element 6 can use a database 7 for asking 10 
necessary data needed for establishing the service requested. The 
database responds 11 back to the processing element or directly to the 

30 application through the firewall. Alternatively, the application can have 
a direct connection to a relevant database. The applications 5 send 12 
responses to the clients' terminals. 

All connections from the clients' terminals go straight to the HTTP 
35 server, which directs them to the relevant application. As can be no- 
ticed in FIG. 2 the firewall has to allow different traffic types to go 
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through due to the different applications. So the firewall has to 
have several "holes" 3 for letting the packets, which are not filtered 
away, go through. As a result of having several "holes" in the firewall 
2A, this solution is also exposed to security risks. 

5 

Also in FIG. 2 the connections to the applications and the back-end 
system are opened (established) outside the service providing ar- 
rangement, exposing the arrangement to thousands of simultaneous 
HTTP requests, which can create an overload situation in the service 
10 arrangement, and even crash the arrangement. 

U.S. patent application 6,141,759 also shows a present solution 
wherein connections are opened (established) outside the firewall mak- 
ing it possible to crash the system of a service provider. The intention 
15 of the invention is to increase the security level of a service providing 
arrangement and eliminate the possibility of crashing the arrangement 
from the outside. 

Summary of the Invention 

20 

The idea of the invention is that a HTTP request coming from a client's 
terminal is picked up by a request handler from a HTTP server. The 
HTTP server contains an application for receiving the client requests 
and sending responses, a queue for the received client requests, and 

25 another queue for the responses. The HTTP server is situated outside 
the firewall, and the request handler inside the firewall, as are back-end 
systems for the request handler as well. Since the request handler re- 
quires the HTTP server to return a client request in the request queue 
as a response to the handler a connection through the firewall is 

30 opened, i.e. established, inside the firewall. In other words, the request 
handler in the firewall controls the traffic through the firewall. This ar- 
rangement eliminates situations where HTTP requests coming from the 
Internet overload the service providing systems. 

35 The request handler sends the requests forward to the back-end sys- 
tems, wherein the requests are handled for establishing responses for 
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sending them back to the clients. The responses are sent through 
the firewall either to the response queue or to a special database from 
where the HTTP server can pick them up. 

Since all connections through the firewall are opened inside the firewall 
the security of the service providing arrangement is more reliable than 
in the present solutions. 

Brief Description of the Drawings 

In the following the invention is described in more detail by means of 
FIGS. 1 - 5 in the attached drawings where 



FIG. 1 illustrates an example of a present solution for processing 
15 HTTP requests, 

FIG. 2 illustrates another example of a present solution for process- 
ing HTTP requests, 

FIG. 3 illustrates an example of an arrangement according to the 
invention, 

20 FIG. 4 illustrates an example of a flow chart describing the method 
according to the invention, and 
FIG. 5 illustrates an example of another arrangement according to 
the invention. 

25 Detailed Description of the Invention 

FIG. 3 shows an example of an arrangement according to the inven- 
tion. A client terminal 1 sends an HTTP request 41 to the HTTP server 
31 . The HTTP server contains an application 32 which handles the re- 

30 ceiving of HTTP requests in an input processing element 33, and send- 
ing of responses back to clients' terminals in an output processing ele- 
ment 34. The received HTTP requests are forwarded 42 for stocking 
them in a request queue 35. The HTTP server also contains a re- 
sponse queue 36 for responses to the clients' terminals. The HTTP 

35 server is located outside a firewall 2B. 
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Inside the firewall there is an element 37, called request 
handler, which handles the creation of connections through the firewall. 
The request handler also directs the HTTP request to a relevant appli- 
cation 39 for establishing the service requested. 

5 

The request handler is preferably middleware software. The definition 
of middleware is not accurate, but usually middleware is considered to 
be a layer or software between the network and the applications. Mid- 
dleware makes advanced network applications much easier to use. 
10 Possible middleware techniques for creating the request handler are, 
for example, CORBA, TUXEDO, COM, DCOM, RPC and RMI. 

The request handler 37 inquires 43 from the request queue 35 in the 
HTTP server 31 if a request is available in the queue, requiring a re- 

15 sponse 44 to the request handler. At the same time when sending 43 
an inquiry, the request handler creates a connection through the fire- 
wall, i.e. open a "hole" 3A in the firewall. If there is a request in the re- 
quest queue, it can be put into a response for the request of the re- 
quest handler and sent it to the request handler through the hole of the 

20 firewall 2B. 

The request handler inquires 45 from an application logic 38, which 
application 39 is the right one for the request. The application logic 
maps 46 (using for example URL information) the application and the 
25 HTTP-request, and returns 47 the mapping information to the request 
handler. The request handler sends 50 the HTTP request to the right 
application 39. It can be possible that the application logic is combined 
with the request handler, but keeping them separate is preferable. 

30 As can be noticed, the request handler acts like a client process, which 
uses outside services, i.e. the HTTP server, the application logic, and 
the applications. 

If needed, the application 39 can use a database 7 for querying 48 the 
35 data needed for establishing the service request. The response data is 
delivered back 49A through the application and the request handler to 
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the response queue through the firewall or to a special database 40 
outside the firewall. The special database is used if the response con- 
tains a great amount of data wherefore it is inefficient or impossible to 
use the response queue. Alternatively, the response data is delivered 
5 back 49B just through the application to the response queue or the 
special database. 

The output processing element 34 asks 51 the response queue 36 or 
the special database 40 responses ready for delivering to the clients' 
10 terminals 1. If there are responses in the queue or in the database the 
responses are conducted 52 to the output processing element 34, 
which delivers 53 them to the clients terminals. 

FIG. 4 shows an example of a flow chart describing the method accord- 
15 ihg to the invention. First, the input processing element 33 in the HTTP 
server receives 60 a HTTP request from a client's terminal. The re- 
ceived HTTP request is stocked 61 in the request queue. The request 
handler, which is on the other side, of the firewall, inquires 62 received 
HTTP requests in the request queue. Due to this the request handler 
20 opens a connection through the firewall - from the safe side of the fire- 
wall. As a response to the inquiry the received HTTP request is re- 
turned 63 to the request handler through the firewall. 

Next, the request handler inquires 64 about a relevant application for 
25 handling the HTTP request from the application logic. As a response to 
this inquiry the application logic maps 65 the relevant application and 
the HTTP request together, and returns 66 the mapping information to 
the request handler. The request handler sends 67 the HTTP request 
to the relevant application. 

30 

The application can ask 68 necessary data, if needed, for a request re- 
sponse from a database. If the data from the database is needed for 
performing the request response, the response from the database is 
conducted 69 to the application. Alternatively, the application can form 
35 the request response without using the database. 



WO 



7 

The application sends 70 the request response either direct to 
the response queue in the HTTP server or to the special database on 
the other (unsafe) side of the firewall, or through the request handler to 
the response queue in the HTTP server or to the special database on 
5 the other side of the firewall. 

The output processing element in the HTTP server inquires 71 about 
request responses from the response queue and the special database. 
If a request response exists the request response in the response 
10 queue or in the special database the output processing element deliv- 
ers (sends) 72 it to the client's terminal. 

The arrangement according to the invention offers a very robust envi- 
ronment for providing services. The arrangement is almost linearly 

15 scalable. The request handler can pick up HTTP requests from several 
HTTP servers and queues as depicted in FIG.. 5. On the other hand, 
there can also be several request handlers, which are capable of deliv- 
ering requests to the same applications. The arrangement is stable as 
well since the HTTP servers and the request handlers can be cross- 

20 connected in a way that the request handlers can pick up a HTTP re- 
quest from the queue of the same HTTP server. 

The processing of HTTP requests can be prioritized. HTTP servers can 
contain several request and response queues, which can be used for 
25 the prioritization. This means that the HTTP server places HTTP re- 
quest into different queues according to certain criteria. The criteria can 
be, for example, the URL requested or a part of it, session ID, client's 
IP address, or client's phone number. Each queue can be connected to 
a different request handler. 

30 

Request handlers can vary from each other. For example, certain re- 
quest handlers are optimized for fast handling, others for taking into 
account security needs, and some request handlers for handling a cer- 
tain type of traffic, such as management traffic or high priority services. 
35 Request handlers can also provide authentication and authorization 



WO 02/082315 



8 

tasks, and also session management. Request handlers 
can also support transaction management. 

As can be noticed, the arrangement according to the invention can be 
5 realized in many ways. The application handling input/output process- 
ing in the HTTP server can be performed by using a common applica- 
tion interface technique, such as CGI, NSAPI, ISAPI, or JavaServlet. 
Request and response queues can act in a FIFO (First In First Out) 
principle. The queues provide read (GetRequest) and write (AddRe- 
10 quest) actions. The services of the queues can be performed using dif- 
ferent techniques, such as middleware (CORBA, TUXEDO, DCOM, 
COM, RPC, RMI). Middleware techniques can be used when perform- 
ing the request handler as mentioned before. 

15 The application logic can also be performed using middleware tech- 
niques. The application logic can be thought to be a service, from 
which the request handler can ask the relevant application for the 
HTTP request under processing. The special database can also be 
seen as a service, through which applications can deliver huge re- 

20 sponses to the HTTP server, past the response queue. There are sev- 
eral ways for providing the database: using a normal file system with, 
for example, FTP or NFS, using some database technique, or modeling 
the database as a service, such as CORBA. 

25 As can be noticed, the request handler preferably acts as a client that 
uses outside services, but this is not the only solution for performing an 
arrangement according to the invention. Although, the invention is de- 
scribed in this text handling HTTP request from clients' terminals, such 
as a Web browser or WAP mobile phone it should be mentioned that it 

30 is possible to handle other kinds of requests as well. According to the 
matters mentioned above, it is clear that the arrangement according to 
the invention can be performed in many ways, in the scope of the in- 
ventive idea. 
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Claims 

1 . An arrangement for providing services in a communication network 
environment, which comprises at least one client's terminal, one server 
5 for connecting the services and the clients' terminals, one back-end 
system for each server, and a firewall between the server and the 
back-end system, characterized in that the server comprises 

an application for receiving service requests from the cli- 
ents' terminals, and for sending responses to the clients' 
1 o terminals, 

a request queue for the received service requests, and 
a response queue for responses to be sent to the clients 
terminals, 

and the back-end system, which handles the performing of the re- 
15 sponses, comprises a request handler to open a connection through 
the firewall for picking up the requests from the request queue. 



2. An arrangement according to claim 1, characterized in that the ar- 
rangement further comprises a special database for keeping the re- 
20 sponses, which are too large for the response queue to handle. 



3. An arrangement according to claim 2, characterized in that the 
application for receiving the service requests further comprises 

- . an input processing element for receiving the service re- 
25 quest and delivering them to the request queue and 

an output processing element for inquiring for the re- 
sponses from the response queue and from the special 
database and for sending the responses to the clients' 
terminals. 



30 



4. An arrangement according to claim 3, characterized in that the 
back-end system further comprises an application logic for mapping to- 
gether the requests from the request handler and applications that 
handle the requests. 



35 
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5. An arrangement according to claim 3 or 4, characterized in that 
the back-end system further comprises at least one database from 
where the applications, which handles the requests, can ask for neces- 
sary data for the responses which are sent to the response queue or to 

5 the special database. 

6. An arrangement according to claim 5, characterized in that the 
special database is performed to be a service for the other elements of 
the arrangement which use the special database. 

10 

7. An arrangement according to claim 6, characterized in that the re- 
quest and the response queue are performed to be services for the 
other elements of the arrangement which use them. 

15 8. An arrangement according to claim 7, characterized in that the 
application logic is performed to be a service for the other elements of 
the arrangement which use it. 

9. An arrangement according to claim 8, characterized in that the re- 
20 quest handler is performed to be a client which uses the services in the 

arrangement. 

10. An arrangement according to claim 1-9, characterized in that the 
service requests are HTTP requests. 

25 

11. A method for providing services in a communication network 
environment, which comprises at least one client's terminal, one server 
for connecting the services and the clients* terminals, one back-end 
system for each server, and a firewall between the server and the 

30 back-end system, the method comprising the steps of receiving a 
service request from the clients terminal in the server and sending a 
response from the server to the clients terminal, characterized in that 
the method further comprises the steps of: 

- stocking the received service request in a request queue 

35 in the server, 



11 

- opening a connection from the 
back-end side of the firewall for inquiring about a request 
in the request queue by a request handler, 

- returning the request from the request queue in the 
5 server side of the firewall to the request handler in the 

back-end side of the firewall, as a response to the inquiry, 
and 

- sending the response from the back-end side of the fire- 
wall to a predetermined element in the server side of the 

10 firewall. 

12. A method according to claim 11, characterized in that the method 

further comprises the steps of: 

requesting a relevant application from an application logic 
15 in the back-end side of the firewall by the request han- 

dler and 

- sending the request from the request handler to the rele- 
vant application for forming the response. 

20 13. A method according to claim 12, characterized in that between the 
steps of inquiring about the relevant application and sending the re- 
quest from the request handler to the relevant application the method 
further comprises the steps of: 

- mapping the relevant application and the request in the 
25 application logic and 

sending the mapping information from the application 
logic to the request handler 

14. A method according to claim 12 or 13, characterized in that the 
30 method further comprises, if needed, the step of asking for necessary 

data from a database and the step of returning the necessary data as a 
response to the relevant application for forming the response. 

15. A method according to claim 12, 13, or 14, characterized in that 
35 the response is sent from the application to the predetermined element, 

which is a response queue in the server. 
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16. A method according to claim 15, characterized in that the re- 
sponse is sent through the request handler. 

5 17. A method according to claim 12, 13, or 14, characterized in that 
the response is sent from the application to the predetermined element, 
which is a special database in the server side of the firewall. 

18. A method according to claim 17, characterized in that the re- 
10 sponse is sent through the request handler. 

19. A method according to claim 11 or 16, characterized in that before 
the step of sending the response from the server to the client's terminal 
the method further comprises the step of inquiring for the response 

15 form the response queue by an output processing element. 

20. A method according to claim 17 or 18, characterized in that before 
the step of sending the response from the server to the client's terminal 
the method further comprises the step of inquiring for the response 

20 form the special database by an output processing element. 
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RECEIVING A HTTP REQUEST FROM A CLIENT'S TERMINAL 
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STOCKING THE RECEIVED HTTP REQUEST IN A REQUEST QUEUE .. — g \ 



62 



INQUIRING FOR HTTP REQUESTS FROM THE REQUEST QUEUE BY A REQUEST HANDLER 



I 



RETURNING THE HTTP REQUEST FROM THE REQUEST QUEUE TO THE REQUEST 
HANDLER AS A RESPONSE TO THE INQUIRY OF THE REQUEST HANDLER 



INQUIRING FOR A RELEVANT APPLICATION FROM A APPLICATION LOGIG B4 

BY REQUEST HANDLER 



"63 



MAPPDIG THE RELEVANT APPLICATION AND THE HTTP REQUEST Hi \ — 65 
THE APPLICATION LOGIC 



RETURNING THE MAPPING INFORMATION FROM THE APPLICATION | — -66 
LOGIC TO THE REQUEST HANDLER AS A RESPONSE 



SENDING THE HTTP REQUEST FROM THE REQUEST HANDLER 
TO THE RELEVANT APPLICATION 



*67 



ASKING FOR NECESSARY DATA IF NEEDED FROM A DATABASE BY 

THE APPLICATION 
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SENDING THE NECESSARY DATA AS A RESPONSE FROM THE DATABASE 
TO THE APPLICATION, IF DATA WAS ASKED 



70 



I 



SENDING A REQUEST RESPONSE DIRECT OR THROUGH THE REQUEST HANDLER TO THE 
RESPONSE QUEUE OR TO A SPECIAL DATABASE ON THE OTHER SIDE OF THE FIREWALL 



I 



INQUDUNG FOR REQUEST RESPONSES FROM THE RESPONSE 
QUEUE OR FROM THE SPECIAL DATABASE BY AN OUTPUT 
PROCESSING ELEMENT 



•71 



RETURNING THE REQUEST RESPONSE TO THE CLIENTS TERMINAL 
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